UK Patent Application ™ GB „„ 2 210 480„=A 

(43) Date of A publication 07.06.1989 



(21) 


Application no doisoio.d 


/C1\ IMT PI 4 


ftnftP 19/19 


(22). 


Date of fifing iQ.08.19BB 




/19\ UK CI fPriition Jl 


(30) 


Priority data 


U4H MIVIW 


^n/ioon fQ9\ n9 m iQfi7 fS3^ LIS 






(56) Documents cited 








/71\ 
\'V 


Appiicani 
Sun Microsystems Inc 


(58) Field of search 

UK CL (Edition J) G4A AMC 




(Incorporated in the USA - Delaware) 


INT CL* G06F 




2550 Garcia Avenue, Mountain View, California 94043, 






United States of America 


(74) Agent and/or Address for Service 


(72) 


Inventors 


Potts Kerr and Co 


William Van Loo 


15 Hamilton Square, Birkenhead, Mersey side, 




John Watkins 


L41 6BR, United Kingdom 




Robert Gamer 






William Joy 






Joseph Moran 






William Shannon 






Ray Cheng 





(54) Flush support 

(57) Hardware and software improvements in workstations which utilize virtual addressing in multi-user operating systems 
with write back caches, including operating systems which allow each user to have multiple active processes. The present 
invention supports data protection and the reassignment of virtual addresses within such a system. Multiple active 
processes have their own virtual address spaces, and an operating system is shared by those processes in a manner 
invisible to user programs. Cache "Flush" logic 33 is used to remove selected blocks from the virtual cache before virtual 
addresses are reassigned. A cache hit detector is adapted to detect cache hits in the shared operating system across 
multiple active user contexts. 




Best Available Copy 

At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply with the formal 
requirements of the Patents Rules 1982. 



1/23 





2/23 



221048 

CPU Bus Address 

VA(15:4) — 
CX(2:G) — 
VA(27:17) — 



VA(16) - 

Cache Address 

VA(15:4) ■ 

Cache Tags 

CX(2:0) - 

VA(27:17) ' 
VA(16) < 
Valid 

Supervisor Prot " 

FIG. 2a 




3/23 



Virtual Address Cache: 
Cache and MMU Prote ction Violations 



2210480 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code = 0x2) 



Cache Tags 

Write Allowed 



Supervisor Access 
Required 



Cache Controls 

Cache Hit 




FIG. 2b 



48 



Cache 

Protection 

Violation 



CPU Bus Controls 

Write Bus Cycle 



User Access 
(Function Code - 0x2) 



MMU Page Map Bits 

Write Allowed 



Supervisor Access 
Required 

MMU Page Valid 




FIG. 2c 



30b 



36 

m y Violation 



MMU 

Protection 



4/23 



32 



Virtual Address Write Back Cache: o O 1 Q 4 6 0 

Address Path *• 



Context Reg 



CX(2.-0) 



Cache Flush 
Logic A 

Match In 

Atn Din 



33 



VA(27:4) 



11 



CPU 



VA(27:0) 



MMU 



RA(27:13) 



27 



CX, VA(27:16) 



Cache Tags 



CX,VA(27:16) 



,23 



CPUVAOE 

\ 



dkVAR 
VA(15:13) 



VAR 

CX, VA(27:1 6) 



CX,VA<27:16) 



Hit 
• nd 
Flush 
Match 



Ctl 



Sel 
VAR/VA 



\ VAR 



x 



MUX VAR/VA 



45 



CX, 

VA(27:13) 



RA(27:13) 



CfcRAR 



51 

J- 



Real Adr Reg 



RAR(27; 



CX t VA(27:16) 



5T>- 



ToCPU Adr/DataBus 



FIG. 3 



5/23 



22104S0 



Virtue! Address Cache: Address Stote Machine 



■ ^Cete (a) j 



Geta <e.*> 



MUX: Sel CPUYA 
Assert Cache Tag OE 



MUX: Sel CPUYA 
Assert Cache Tag OE 
Translate CPU YA 



State (a) 



State (c) 



Assert Bus Ack to CPU 
Assert Bus Retrg to CPU 
MUX: Sel CPUYA 
Assert Cache Tag OE 
ClkTag YA to YAR 
Translate CPU YA 



State 
<e.»> 





MUX: Sel CPUYA 
Translate CPU YA 



State 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Set Prot Viol bit in 
Bus Error Reg 
MUX: Sel CPU YA 
Assert Cache Tag OE 
ClkTag YA to YAR 
Translate CPU YA 



MUX: Sel CPU YA 
ClkCPU AdrinRAR 
Translate CPU YA 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



State <g> 



State 
(c.v) 



Assert Bus Ack to CPU 
MUX: Sel CPUYA 
Assert Cache Tag OE 
ClkTagYA to YAR 
Translate CPU YA 




State 
(eh) 



Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Set ProtYiol bit in 
Bus Error Reg 
MUX: Sel CPUYA 
Translate CPUYA 
Deassert Mem Adr Strobe 



State 

(i.v) 



FIG. 4a 



6/23 



Virtual Address Cache: Addre ss state Machine 



6 



6eto CM) 



MUX: Sel YAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



I 



MUX: Sel VAR 
Translate Cache YA 
Assert CPU YA OE 
Update Cache Tags 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



MUX: Sel YAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Mem Adr Strobe 
Assert Cache to Mem OE 



State <!.■) 



State (fc) 



State (n) 




MUX: Sel YAR 
Translate Cache YA 
Clk Adr to RAR (at p) 
Assert CPU YA OE 
Deassert Mem Adr Strobe 



State (•) 



MUX: Sel YAR 
Translate Cache YA 
Assert CPU YA OE 



MUX: Sel YAR 
Translate Cache YA 
Assert CPU YA OE 
Clk YA to YAR (ats) 



MUX: Sel YAR 
Translate CPU YA 
Assert CPU VAOE 



State (q) 



State <*> 



State (■) 




MUX: Sel YAR 
Translate CPU YA 
Update MMU Statistic Bits 
Assert CPU YA OE 
Update Tag Yalid Bit 



State (v) 



^6«f («) J 



FIG. 



4b 



7/23 



2210480 



virtual Aggress rarn e pata Path 



CPU A 



VAC 15:3) 




CPU Write 
O.E. 



Cache Data 



Date (127:64) 



Data (63:0) 



Sel JfA(2)=1 
SelifA(2M> ^ 

Data Reg O.E.\ 



A(3)=0 
A(3)=1 



CPU Read O.E. 



(63:32) 



(31:0) 



Clk Data Reg — > Data Reg ( 63:0) 



Clk 

WrlBk 



(31:0) 



\ 



Cache Data O.E. 



> 



Write Back Buffer 

D( 127:64) 



Write Back O.E. 



/ 



D(63:0) 

s 7- s 7- 



(63:32) 



CPU Adr/Data Bus (63:0) 



To Real 
AdrRag 



/\/ /\J ~ Cache to Mem O.E. 



hem Bus ADC 63:0) 

(31:0) 



^ Mem to Cache O.E. 
(63:32) 



Main 
Memory 



D( 127:64) 



D(63:0) 



A(3)=0 
A(3)=1 



FIG. 5 



8/23 



2210480 



Virtual Address Cache: Data state Machine 




f Sata (l) J 



Assert CPU Write OE 



Assert CPU Write OE 



i 



ote (e.vn) 



Dessert CPU Write OE 
Assert Bus Ack to CPU 
Assert Bus Error to CPU 



Write CPU Data into Cache 
Deassert CPU Write OE 
Assert" Bus AcktoCPU 



State 
(a.vr) 



State 

(c.vr) 




State 

(e.w> 



State 
(e.vh) 



Assert CPU Read OE 



Assert CPU Reed OE 




eto (e.rm) 




Deassert CPU Read OE 
Assert Bus Ack to CPU 
Assert Bus Error to CPU 



Read Cache Data to CPU 
DeassertCPU ReadOE 
Assert Bus Ack to CPU 



State 
(a.rd) 



State 

(c.rd) 



State 
(e.rv) 



State 
(e.ra) 



FIG. 6a 



V 



9/23 



221 



0480 



Virtual Address Cache: Data State Machine 



te (e.vn) 



Deassert CPU Write OE 
Assert BusAcktoCPU 
Assert Bus Rretry to CPU 



State 



to (e.r») 



Deassert CPU Read OE 
Assert BusAcktoCPU 
Assert Bus Retry to CPU 



Assert Cache Data OE 




Assert Bus Ack to CPU 
Assert Bus Error to CPU 
Assert Cache Data OE 



Gat© (a) 



State 
(e.r«> 



State (9} 



State 

(i.v) 



Assert Cache Data OE 
Clk Write Beck Bufer 
Invert Cache Adr bit A(3> 



Assert Cache DataOE 



Assert Cache Data OE 
Clk Write Back Bufer 
Invert Cache Adr bit A(3) 




Null 



c 



Null 



Goto (<) 



State 
(•-■> 



State <k) 



State (■) 



State 
(•-vt) 



State (e) 



FIG. 6b 



10/23 



2210480 



Virtual Addreaa Coche: Polo Stote Hochine 
(Write B«3 C«cle) 




□k Data Reg 
Merge CPU Data vith 

Data Reg: 
Assert CPU Write OE 
Assert Date Reg OE for 

Other Bytes 



Assert CPU Write OE 
Assert Data Reg OE for 
Other Bytes 
Update Date Cache 
invert Cache Adr bit A(3) 



Gate 



State (q.v) 




State (s.v) 



c 



Gato (a) 



FIG. 6c 



Clk Data Reg 
peassert CPU Write OE 
Assert Data Reg OE for 
All Bytes 




Assert Data Reg OE for 
All Bytes 
Update Ddta Cache 



Assert Memory Busy 
Assert Start Write 
Back Cycle 



State (a.v) 



State (v.v) 




State («.v) 



11/23 



2210480 



Virtual Address Cache: Doto State Machine 
(Read Bas Cfrie) 



^Cate <«.r)j 



Clk Data Reg 
Assert CPU Read OE 
Assert Date Reg OE for 
All Bytes 



Assert CPU Read OE 
Assert Data Reg OE for 
All Bytes 
Update Data Cache 
invert Cache Adr bit A(3> 



State (*.r) 




State (s.r) 



I 



Goto (a) 



FIG. 6d 



Clk Data Reg 
Deassert CPU Read OE 
Assert Data Reg OE for 
All Bytes 



Assert Data Reg OE for 
All Bytes 
Update Date Cache 




Assert Memory Busy 
Assert Start Write 
Back Cycle 



State (a.r) 




State (v.r) 



State (y.r) 



12/23 



22104E0 



Write Back State Machine 




Assert Memory Busy 
Assert Memory Address Strobe 
Assert Cache to Memory O.E. 




Assert Memory Busy 
Deassert Memory Adr Strobe 
Assert Cache to Memory OE 



Assert Memory Busy 
Assert Memory Dote Strobe 0 

(First 64 bit transfer) 
Assert Cache to Memory O.E. 



Mem 
DateAckO?. 



Assert Memory Busy 
Deassert Memory Data Strobe 0 
Assert Cache to Memory O.E. 



Assert Memory Busy 
Assert Memory Data Strobe 1 

(Second 64 bit transfer) 
Assert Cache to Memory O.E. 




FIG. 7 



13/23 



rarhg Write Miss - Best Case Timing 



States 



nnu 



L 



I I 

TrenlateCPU 



VlrtAddr. 



Translate Cache 
VlrtAddr. " 



I I 

TrenlateCPU 
VlrtAddr. 



J 



Cache Tag 

rigt 



VAHgt. 



MUX Sel 
VAR./ VA 



Cache Miss 
Read 



L Cache J 

J* - TegO.E. 



CPUVAO.E. 



I Cache I Clk 
Hit/ TegVA 
Miss? to VAR 



MUX Sel CPU VA 



Clk RA 
ItoRARl 



k- cpu ~H k— 

Write OE 



Update 
Tags 



|Update| 
Tag 
Valid 



IcpuvJ 

I to VAR | 



Clk RA 
ItoRARl 

MUXSelVAR 



Cache Data O.E. 



Clk 
IWrtBk 

Bfr; 
Invert 
AdrA3 



Clk 
IWrtBk] 

Bfr ; 
Invert 
AdrAJ 



( Merge CPU Data with Data Reg) 
CPU Write 0Ef#- 
Data Reg O.E. 



Clk 
Data 
Reg 



Update 
Data 
Cache; 
Invert 
AdrA3 



Clk 
Data 
Reg 



Update 
Data 
Cache 



CPU Bus 
Intrtface 
Cntls 



k-cpu .+ 
Mr Strobe 

I Retry 
to 

CPU 



CPU 
Adr Strobe 



Ack 
to 

CPU 



FIG. 8 



14/23 



rarhe Read m i** - Rest rase Timing 



States 



nnu 



Cache Tag 
Hgt 



YAHgt. 



MUXSel 
VAR / VA 



Cache Miss 
Read 



njmrmjuiniinj^ 



i i 

TranlateCPU 
VtrtAddr. " 



I I I I 



Translate Cache 
VlrLAddr. 



I I 

TranlateCPU 
VirtAddr. " 



h Cache J 
T93O.E. ^1 



CPU VA O.E. 



Update 
Tags 



(Update 
Tag 
Valid 



I Cache I Clk 
Hit/ TagVA 
Miss? to VAR 



Clk RAI 
toRARi 



Clk I 
DPUVd 
to VAR 



MUXSel CPU VA — »U- 



ClkRA 
itoRARl 



MUXSel VAR 



rCPU 
ReadOE 



Cache Data O.E. 






-*|CPUReadO£ |«- 










Data Reg O.E. * 


Clk 




Clk 




Clk 


Update 


Clk 


WrtBk 




WrtBk 




Data 


Data 


Data 


Bfr; 




Bfr; 




Reg 


Cache; 


Reg 


Invert 




Invert 






invert 




Mr A3 




!rVJrA3 






Adr A3 





Update 
Data 
Cache 



CPU Bus 
Intrtface 
Cntls 



U- cpu _n 

J Adr Strobe 

I Retry 
to 

CPU 



CPU 
Adr Strobe 



Ac* 
to 

CPU 



CPU 
Latch 
Data 



FIG. 9 



15/23 



22^0480 



Block Read Cy cle 
Date Bbs (63:0) 

CPU Controls 

Addr Strobe 

Data Act: 0 

Data Ac* 1 
Memory Controls 
Addr Ack 

Data Strobe 0 

Data Strobe 1 

Write Bock Cqcle 
DtU Boa (63:0) 

CPU Control* 

hem Busy 

Addr Strobe 

Data Strobe 0 

Date Strobe 1 
Memory Controls 
MdrAck 



Memoru Dotn Bus 

From CPU From Mem 



From Mem 



^fcir (27*^ ^Data (64^ — ^teT(64) 




\ 




-A— 



fig. ioa 



\ 



From CPU 



From CPU 



From CPU 



— ^Addr ( 27^ ^Data ( 64) ^ Data (64)^ — 



\ r 



\-j 



DstsAckO 



Date Ack 1 



Kote: All Control Signals ore Negative Active Signals 



FIG. 10b 



16/23 



2210480 



Cache Flush Block Diagram 



CPU Bus Grant 



t lush Command Decode 



CPUVA(3128) — 
CPU FuncCode (2:0) 
Cycle Decode Timing 



CPU D{1:0) 



CPU A{27:9) 



FIG. 1 1 



Segment Match 
Page Match 
Context Match 



Cache Controls 
Memory Busy 



A(31:28)«0xA i 
FC(2:0)«0x3 ~ A ^ 

J 49 



48 

> D(1:0)-'0V 

• D(1:0)= , 10 t 

• D(1:0)«1V 



CDc <>-"^ 



Bus Request 
Logic: 

CPU Grants Bus 
Mastership 
to Start Flush 
State Machine 



D C 



■ — 5" 



D C 



D C-i 



7 

Flush Adr Reg 



52 



7" 



L. +1 



50' 



A(8:4) 



Context 
Flush 



Page 
Flush 



Segment 
Rush 




Bus Request to CP 
Bus Grant Ack to Cf 



Rush A(27:9) 



Flush A(8:4) 



Flush Controls 



17/23 



221CAE0 



Virtual Address Cache: 
Cache Hit and Flush Match Definition 

Cache Address 

VA(15:4) 

Cache Tags 

CX(2:0) 
VA{27:17) 
VA(16) 
Valid 

Supvsr Prot 

Flush Address 

VA(15:4) 

CX(2:0) 
VA(27:17) 
VA(16) 




0 



/\ Contex 
- A H F j ush 
J Match 



FIG. 1 2 



Segme 

Flush 

Match 



J A U Flush 
J Match 



18/23 



2210480 



Flush State Machine: 
Flush Command Decode and PVH A State Machine 




State (c) 



Latch Rush Addr and 
Type of Flush Cmd 
Assert Bus Request to CPU 
Assert Bus Acknowledge 
to CPU to end cycle 
Assert Flush Request 



State (e) 



f Sato 
kDYMA ftcq} 




Assert Bus Grant Ack to CPU 
Deassert Bus Request 


1 





|EtherTe»tJ 



FIG. 1 3a 



19/23 



22104^0 



Flush Stole Mochine: 
DVHA Stole Machine- con't 



Assert Flush Go 
Assert Bus Grant Ack to CPU 



Assert Flush Go 
Assert Bus Grant Ack to CPU 



£ 



Assert Bus Grant Ack to CPU 



( Goto \ 
^Ether Tesy 




Assert Bus Grant Ack to CPU 
Perform Ethernet Bus Cycle 




FIG. 13b 



20/23 



221C4B0 



Flush State Machine: 
Flush Compere State Machine 




Assert Flush Request 
Initialize Flush S/li; 
Set Incr Count=0 
for Start Address 
Set Flush Base Adr = 
Flush Cmd Address 
Set Adr bit A3=0 




lncrCnt=lncr Cnt+1 
Flush Adr=Base Adr+lncr 
Assert Cache Tag OE 
Assert CPU Write OE 



Assert Cache Tag OE 
Assert CPU Write OE 



State (a) 



Assert Cat 
Assert CPl 


;he Teg OE 
J Write OE 







State (c) 



FIG. I3c 



Goto 
(Match) . 



21/23 

Flush Stote Machine: 
Flu9h Match State Machine 



2210480 




State 
(gn) 



State (9) 



MUX: Sel YAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Cache Data OE 
Clk Write Back Buffer 
SetAdr bit A3=1 



State (i) 



MUX: Sel VAR 
Translate Cache VA 
Assert CPU YA OE 
Negate Yalid Tag 
Assert Cache Data OE 



State (k) 



1 


t 




MUX: Sel VAR 
Translate Cache YA 
Assert CPU YA OE 
Assert Cache Dats OE 
Clk Write Back Buffer 
SetAdr bit A3=0 



I 



State (m) 



MUX: Sel YAR 
Translate Cache YA 
Clk Adrto RAR (at p) 
Assert CPU YA OE 



State (o) 



Assert Write Back Req 
(to Flush ReqS/M) 



State (q) 




Assert Memory Busy 
Assert Start Write 
Back Cycle 



C 



State (s) 



Gote A 
(Idle) 



FIG. 13d 



22/23 



22104 



flush State Machine: 
f|ush CoitlPr"- ««»tP Machine, con't 



( 



fete 
(Match) 



^Flush Match? 




FIG. I3e 



23/23 221 0480 



States 



MHO 



farm* Flush - F1ii«sh Matrh Tfmlno 



ruiminjuijuuuii 



i i i i i 



i i i 

Translate Cache_ 
" VIrtAddr. 



Cache Tag 
Mgt 




Cache 


1» 


< 


Tag O.E. 




VAflflt. 


Incr. 
Flush 
Count 




Flush 
Match 
? 


Clk 
TagVA 
toVAR 



N CPUVA O.E. M 

' | Negate | 1 
Valid 
Tag 



Clk RA 
toRAR 



MUXSel 
VAR / VA 



Cache Flush 
Match - Load 
Write Beck Bfr 



r- cpu — H k— 
Write OE 



|^ MUX Sel VAR _»| 



Cache Date O.E. 



Clk 




Clk 




Set 


Write Back 


WrtBk 




WrtBk 




Wrt 


Reqd? 


Bfr; 




Bfr; 




Back 


Then set 


Set 




Set 




Req 


Mem Busy; 


A3-I 




A3-0 






Start W/B 



FIG. 14 



- 1 - 

FLUSH SUPPORT. 
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This invention is directed to certain hardware and 
software improvements in workstations which utilize virtual 
addressing in multi-user operating systems with write back 
caches, including operating systems which allow each user to 
have multiple active processes. In this connection, for 
convenience the invention will be described with reference 
to a particular multi-user, multiple active proceeses 
operating system, namely the Unix operating system. 
However, the invention is not limited to use in connection 
with the Unix operating system, nor are the claims to be 
interpreted as covering an invention which may be used only 
with the Unix operating system. 

In a Unix based workstation, system performance may be 
improved significantly by including a virtual address write 
back cache as one of the system elements. The present 
invention describes an efficient scheme for supporting data 
protection and the reassignment of virtual addresses within 
such a system. The invention features support for multiple 
active processes, each with its own virtual address space, 
and an operating system shared by those processes in a 
manner which is invisible to user programs. 

Cache "Flush" logic is used to remove selected blocks 
from the virtual cache when virtual addresses are to be 
reassigned. If a range of addresses (a virtual page 
address, for example) is to be reassigned, then all 



instances of addresses from within this range must be 
removed, or " flushed" , from the cache before the new address 
assignment can be made. A cache block is "flushed" by 
invalidating the valid bit in its tags and writing the block 
back to memory, if the block has been modified. The "Flush" 
logic includes logic to identify "Flush" commands within 
"Control Space"; logic to match particular virtual address 
fields, within a Flush command, to corresponding virtual 
address fields either within the cache f s block address space 
or its tag virtual address field; and (optional) logic to 
flush multiple cache block addresses as a result of a single 
"Flush" command issued by the CPU (or DVMA device, if 
allowed) • It also includes logic to invalidate the cache 
valid tag on matching cache blocks and logic to enable 
modified matching blocks to be written back to memory. 

The present invention includes both hardware and 
specific "Flush" commands inserted within thfe operating 
system kernel. 

pRXEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram showing the main components 
©f a workstation utilizing virtual addresses with write back 
cache. 

Figure 2a is a schematic diagram of cache "hit" logic 

25. 



- 3 - 

Figure 2b is a schematic diagram of a circuit for 

detecting a cache protection violation- 
Figure 2c is a schematic diagram o£ a circuit fcr 

detecting a MMU protection violation. 

Figure 3 is a detailed block diagraa shoving the 
address path utilized by the virtual address cache of the 
present invention. 

Figure 4 (4 (a) , 4 (b) ) is a flow diagraa of a state 
machine implementation for certain controls related to the 
addressing of a virtual address vrite back cache. 

Figure 5 is a detailed block diagram showing the data 
path utilized by the virtual address path of the present 
invention. 

Figure 6 (6a, 6b, 6c and 6d) is a flou diagram of a state 
machine implementation for certain controls related to data 

transfers to and from a 'virtual address vrite back cache 
(states (a) - (o)). 

Figure 7 is a flow diagram of a state machine for 
implementation for controlling Write Back bus cycles to 
memory. 

* Figure 8 is a timing diagram for best case timing for 
a cache vrite miss. 



Figure 9 is a timing diagram for best case timing for 
a cache read miss.* 

Figure 10a is a timing diagram of the memory bus cycle 
for performing a block read cycle. 

Figure 10b is a timing diagram of the memory bus cycle 
for performing a write back cycle. 

Figure 11 is a schematic diagram showing the cache 
flush implementation of the present invention. 

Figure 12 is a schematic diagram showing the logic for 
detection of Context Flush Match , Segment Flush Match and 
Page Flush Match. 

Figure 13 (13a - 13e) is a flow diagram of a state 
machine implementation of a cache flush initiated by the 
issuance of a flush command. 

Figure 14 is a timing diagram for a cache flush. 

DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 shows the functional blocks in a typical 
workstation using virtual addresses in which the present 
invention is implemented. 

Specifically, such a workstation includes a 
microprocessor or central processing unit (CPU) 11, cache 
data array 19, cache tag array 23, cache hit comparator 25, 
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memory management unit (HMD) 27. main memory 31. vrite back 
buffer 39 and workstation control logic 40. Such 
workstations may. optionally, also include context ID 
register 32. cache flush logic 33. direct virtual memory 
access (DVMA) logic 35, and multiplexor 37. 

In the present invention, various changes are made to 
cache flush logic 33, cache hit comparator 25 and 
workstation control logic 40 which improve the performance 
of a virtual address write back cache. 

p^^pMnn of Np^c^rv ElemPtttn of Workstation 

CPU 11 issues bus cycles to address instructions and 
data in memory (following address translation) and possibly 
other system devices. The CPU address itself is a virtual 
address of (A) bits in size which uniquely identifies bytes 
of instructions or data within a virtual context. The bus 
cycle may be characterized by one or more control fields to 
uniquely identify the bus cycle. In particular, a 
Read/Write indicator is required, as well as a -Type- field. 
This field identifies the memory instruction and data 
address space as well as the access priority (i.e., 
-Supervisor" or -User" access priority) for the bus cycle. 
A CPU which may be. utilized in a workstation having virtual 
addressing and capable of supporting a multi-user operating 
system is a MC68020. 



Another necessary element in a virtual address 
workstation with write back cache shown in Figure 1 is 
virtual address cache data array 19, which is organized as 
an array of 2» blocks of data, each of which contains 2 K 
bytes. The 2« bytes within each block are uniquely 
identified with the low order M address bits. Each of the 
2* blocks is uniquely addressed as an array element by the 
next lowest N address bits. As a virtual address cache, the 
(K+H) bits addressing bytes within the cache are from the 
virtual address space of (A+C) bits. (The (C) bits are 
context bits from optional context ID register 32 described 
below.) The (N+M) bits include, in general, the (P) 
untranslated page bits plus added virtual bits from the 
(A+C-P) bits defining the virtual page address. 

Virtual address cache data array 19 described herein is 
a "direct mapped" cache, or "one way set associative" cache. 
While this cache organization is used to illustrate the 
invention, it is not meant to restrict the scope of the 
invention which may also be used in connection with multi- 
way set associative caches. 

Another required element shown in Figure 1 is virtual 
address cache tag array 23 which has one tag array element 
for each block of data in cache data array 19. The tag 
array thus contains 2« elements, each of which has a Valid 
bit (V) , a Kodif ied bit (M) , two protection bits (P) 
consisting of a Supervisor Protect bit (Supvsr Prot) and a 
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Write Allowed bit, and a virtual address field (VA, and 
optionally CX) as shown in Figure 3. The contents of the 
virtual address field, together with low order address bits 
used to address the cache tag and data arrays, uniquely 
identify the cache block within the total virtual address 
space of (A+C) bits. That is, the tag virtual address field 
must contain ((A+C) - (M+N) ) virtual address bits. 

Cache "Hit" logic 25 compares virtual access addresses 
with the contents of the virtual address cache tag address 
field. Kithin the access address, the lowest order M bits 
address bytes within a block; the next lowest N bits address 
a block within the cache; and the remaining ((A+C) - (M+N) ) 
bits compare with the tag virtual address field, as part of 
the cache M hit" logic. 

The cache "hit" logic must identify, for systems with a 
shared operating system, accesses to user instructions and 
data, and to supervisor instructions and data. A "hit" 
definition which satisfies these requirements is illustrated 
in Figure 2a which comprises comparators 20, AND gate 22, OR 
gate 24 and AND gate 26. 

MMO 27, which translates addresses within the virtual 
space into a physical address, is another required element. 
MMU 27 Is organized on the basis of pages of size (2*) 
bytes, which in turn are grouped as segments of size (2 s ) 
pages. Addressing within a page requires (P) bits. These 
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(P) bits are physical address bits which require no 
translation. The role of KMU 27 is to translate the virtual 
page address bits ((A+C-P) or (A-P)) into physical page 
addresses of (MM) bits. The composite physical address is 
then (KM) page address bits with (P) bits per page. 

HMO 27 is also the locus for protection checking, i.e., 
comparing the access bus cycle priority vith the protection 
assigned to the page. To illustrate this point, there are 
two types of protection that may be assigned to a page 
namely, a Supervisor/User access designator and a Write 
Protect/write Allowed designator. Although the subject 
invention is not limited to such types of protection, given 
this page protection, a "Protection Violation" can result if 
either a "User" priority bus cycle accesses a page. with 
-Supervisor" protection; or if a "Write- bus cycle accesses 
a page with a "Write Protect" designation. 

ft 

The application of KMU protection checking through the 
KMU is shown in Figure 2c which comprises inverter 28, AND 
gates 30a and 30b, OR gate 34 and AND gate 36. In addition, 
with a virtual address write back cache, the concept of 
protection checking can be extended to cache only CPU cycles 
which do not access the MMTJ. Such cache only protection 
logic is shown in Figure 2b comprising inverter 42, AND 
gates 44a and 44b, OR gate 46 and AND gate 48. 
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Also shown in Figure 1 is main memory 31 which is 
addressable within the physical address space; control or 
Bain memory access is through workstation control logic 40. 

Write back buffer 39 is a register containing one block 
of cache data loaded from cache data array 19. Write back 
buffer 39 is loaded whenever an existing cache block is to 
be displaced. This nay be caused by a need to update the 
cache block with new contents, or because the block must be 
flushed. In either case, in a write back cache, the state 
of the cache tags for the existing cache block determine 
■whether this block must be written back to memory. If the 
tags indicate that the block is valid and modified, as 
defined below, then, the block contents aust be written back 
to memory 31 when the cache block is displaced. . Write back 
buffer 39 temporarily holds such data before it is written 
to memory. 

Workstation control logic 40 controls the overall 
operation of the workstation elements shown in Figure 1. in 
the preferred embodiment, control logic 40 is implemented as 
several state machines which are shown in Figures 4, 6, 7 
and 13 as will be described more fully below in conjunction 
with the description of cache flush logic 33, portions of 
which axe also, in the preferred embodiment, integrated into 
the workstation control logic. 

Description of Optional Elements of WorVst^Jr^ 
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Context ID register 32 is an optional external address 
register which contains further virtual address bits to 
identify a virtual context or process. This register, 
containing C bits, identifies a total of (2**C) active user 
processes ; the total virtual address space is of size 
2** (A+C) 

An important component in this virtual address space of 
2**(A+C) bits is the address space occupied by the operating 
system. The operating system is common to all user 
processes, and so it is assigned to a common address space 
across all active user processes. That is, the .(C) context 
bits have no meaning in qualifying the addresses of pages 
within the operating system. Rather, the operating system 
is assumed to lie within a common, exclusive region at the 
top of the (2**A) bytes of virtual address space for each 
active context. No user pages may lie within this region. 
So the operating system page addresses for two distinct usej 
processes are identical, while the user pages for the two 
processes are distinct. All pages within the operating 
system are marked as having "Supervisor" protection. 

Cache flush logic 33 is also an optional element in a 
workstation. However, cache flush logic 33 is included, an 
modified as described in detail below in order to improve 
the performance of a virtual address, write back cache 
system. Briefly however, cache flush logic 33 operates as 
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follows. 2f a range of addresses (a virtual page address, 
for example) is to be reassigned, then all instances of 
addresses from within this range must be removed, or 
"flushed", from the cache before the new address assignment 
can be made. X cache block is "flushed" by invalidating the 
valid bit in its tags and writing the block back to memory, 
if the block has been modified. 

In addition to CPU 11 as a source of bus cycles, the 
workstation may include one or more external Input/Output 
(1/0) devices such as DVKA logic 35. These external I/O 
devices are capable of issuing bus cycles which parallel the 
CPU in accessing one or more "Types" of virtual address 
spaces. The virtual address from either the CPU 11 or DVMA 
logic 35, together with the address in context ID register 
32, is referred to as the access address. 

Another optional element is data bus buffer 37, which 
in the preferred embodiment is implemented as two buffers to 
control data flow between a 32 bit bus and a 64 bit bus. 
Such buffers are needed when the CPU data bus is 32 bits and 
the cache data array data bus is 64 bits. 

p» C r r *p*lon of Pigments T Tn ^ie to the Invented Workstation 

In the present invention, the definition of a cache 
"Hit" is modified "to take into account the use of a shared 
operating system across multiple active user contexts, and 
the access priority and page protection. By bo doing, an 



•ff icient indication of a protection violation vithin the 
vrite back virtual address cache can be achieved. 
Specifically, to implement the protection definition 
presented above, the following cache "Hit" definition is 
utilized. 

A cache "Hit" has three requirements: 

1) The cache block must be marked as having valid 
contents . 

2) Ignoring the (C) context bits, the access virtual 
address bits (A-(N+M)) must match the corresponding tag 
virtual address field bits (A-(N+M)), at the cache 
block addressed by the (N) bus access bits. 

3) Either the (C) bits of the access context ID must 
match the corresponding (C) context bits in the cache 
tag virtual address field, or the cache tag Supervisor 
protection bit must be set active. 

This definition of a cache "Hit" enables cache 
protection checking to be applied directly to the virtual 
address cache, rather than defined through an MMU check 
during cache miss handling. A "Protection Violation- on a 
cache "Hit" results: 

1)" if the acoess bus cycle has "User" priority and the 
cache block has "Supervisor" protection; or 



2) if the access is' a Write bus cycle and the cache 
block has Write Protection. 
An implementation of cache hit detector 25 according -to the preser 
invention is shown in Figure 2a described hereinabove. 

The present invention utilizes a set of "Flush" 
commands in the Control Space to efficiently implement 
virtual address reassignment in a virtual address write back 
cache. 

In general, Flush commands are bus cycles in Control 
Space which specify, for each unique type of Flush command, 
one or more virtual address fields to be compared with 
corresponding virtual address fields, in the- virtual address 
cache tags. "Matching" address fields cause the hardware to 
"flush" the cache block. To ";flush" the cache block means 
thats 

1) X matching cache block that is marked as both 
"Valid" and "Modified" is written back to memory. This 
requires a cache block "write back" bus cycle to the main 
aeaory. X "write back" bus cycle writes the contents of an 
entire cache block into main memory at the appropriate 
physical address. Xs a part of this cycle, the virtual 
address, identifying the cache block is translated through 
the HKtfinto a physical aemory address. During this 
translation, protection checking for the cache block is 
inhibited. The address translation through the MKU is 
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completed prior to returning control to the processor at the 
conclusion of the flush command. 

2) Any matching cache block that is "Valid", whether 
"Modified" or not, is marked as invalid. 

As described, the "write back" bus cycle requires the 
translation of the cache block virtual address into a 
physical address. The concept of the flush command and 
"write back 1 * bus cycle can also be extended to virtual 
address caches which contain both virtual address and 
physical address tag fields. If a physical address tag 
field is present, no translation is required at the time the 
"write back" bus cycle to main memory is performed. 
However, the present invention is directed to the use of 
virtual address tags to support a virtual address write back 
cache • 

The flush command as described above applies to a 
single cache block. The application of the flush command 
can also be extended so that a single flush command 
activates hardware which checks multiple cache blocks, 
flushing those blocks which match the address fields of the 
flush command. It is only required that the address 
translation of the last cache block flushed be concluded 
prior to returning control to the processor at the 
conclusion of the command. 



Three specific flush commands are defined below. While 
other similar commands may be defined, these three are 
particularly useful in effectively restricting the scope of 
a "Flush* command to a minimal address range. These "Flush" 
commands are also effective in implementing a multiple 
context, shared operating system address space. 

1. Context Match Flush Command 

The Context Match Flush command flushes from the cache 
all cache blocks within a specified context which are from 
User protected pages. It specifies a context identifier of 
(C) bits. The match criteria is to require first, that the 
cache tags identify the block as having User protection; and 
second, that the (C) bit field of the Flush command match 
the corresponding (C) bit Context identification field of 
the tags. 

The Context Match Flush command is used to ensure cache 
addressing consistency whenever a new active context 
replaces an old context in the MMU. The Context Match Flush 
must be performed before the old context references are 
removed from the MHD, since the MMU is required to translate 
the cache blocks 1 virtual addresses. 

2. ;Page Match Flush Command 

The Page Match Flush command flushes from the cache all 
cache blocks within a specified page, regardless of the page 
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protection. It specifies a page address of (A+C-P) bits. 
The natch criteria is to require that first, the (A-P) bit 
field of the Flush command, which identifies a virtual page 
address within a Context, match the corresponding (A-P) bits 
to identify the virtual page address of a given cache block. 
These (A-P) bits may be in the cache tag virtual address 
field or in a combination of both the cache access address 
and the cache tag virtual address field, depending on the 
page size and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block's 
Supervisor access protection tag is active; "or ii) the 
context ID register of (C) bits match the cache block's 
corresponding Context ID tag field of (C) bits. 

The Page Match Flush command is used during page 
management to purge all references to a virtual page - with 
either Supervisor or User protection - from the cache. It 
must be performed before the MMU is updated to remove the 
page, since the MMU is required to translate the cache 
blocks* virtual addresses. 

3. Segment Match Flush Command 

The Segment Hatch Flush command flushes from the cache 
all cache blocks within a specified segment, regardless of 
the page protection. It specifies a segment address of 
((A+C)-(P+S)) bits, since the Begment size is (2**S) pages. 



The match criteria is to require that first, the (A-(P+S)) 
bit field of the Flush command, which identifies a segment 
within a Context, match the corresponding (A-(P+S)) bits 
identifying a segment for a given cache block* These (A- 
(P+S)) bits may be in the cache tag virtual address field or 
in a combination of both the cache access address and the 
cache tag virtual address field, depending on the segment 
size, the page size, and the size of the cache. 

The second match criteria is to require that one of the 
following two conditions is met: i) the cache block »s 
Supervisor access protection tag is active; or ii) the 
context ID register of (C) bits match the cache blocks 
corresponding Context ID tag field of (C) bits. 

The Segment Match Flush command is used during page 
management to purge all references to a virtual segment - 
with either Supervisor or User protection - from the cache. 
It may be required, depending on the structure of the KMU, 
whenever the pages of an entire virtual segment must be 
reassigned to a new virtual segment. It must be performed 
before the KMU is updated to remove the segment mapping, 
since the KMU is required to translate the cache blocks 1 
virtual addresses. 

Flush Command Usage 

The three "Flush" commands defined above, together with 
the respective "match" criteria, are executed only by the 
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operating system within the Unix kernel. The placement of 
flush commands within the kernel is described within 
Appendix A* By proper placement of "Flush* commands within 
the kernel , virtual address reassignment for a Unix system 
may be implemented to support a virtual address write back 
cache. 

The set of flush commands defined above, when used in 
the Unix kernel as shown in Appendix A, implement a 
mechanism to support virtual address reassignment, as 
required by a virtual address cache, for a Unix system with 
multiple active contexts and an operating system shared 
across those contexts for workstations having either write 
through or write back caches. 

The flush commands, when used in the Unix kernel as 
shown in Appendix A, support a virtual address write back 
cache within a Unix system so that the use of such a cache 
is transparent to user application programs. No changes are 
required to user programs to take advantage of the memory 
speed improvements inherent in a virtual address write back 
cache. 

Additionally, the flush commands, when used in a Unix 
kernel as shown in Appendix A, support a virtual address 
write back cache implementation which contains only a 
virtual address tag field for block identification, not a 
physical address tag field. Avoiding the addition of a 
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physical address tag field minimizes the number of cache 
tags required for the virtual address write back cache. A 
vrite back cache requires that at some point, any cache 
block which has been modified must be written back into main 
memory. This "write back" operation may take place either 
when the cache block is replaced by new block contents (the 
normal block replacement on a cache "miss"), or when the 
cache block 1b flushed prior to reassigning a range of 
virtual addresses containing this cache block. 

If the cache tags contain no physical address field, 
then the virtual address tags must be translated into a 
physical address before the cache block may be written into 
memory. In the case of cache flushes, this implies that all 
address translations of cache block virtual address fields 
which result from a flush match must be completed prior to 
the operating system's reassignment of the virtual address 
range within the HMtf. Two features of the invention are in 
part responsible for ensuring that this requirement is met: 

1) first, that the flush command requires the 
completion of the cache block virtual address translation 
before control is returned to the processor; 

2) and second, that the flush commands are structured 
in the kernel, as shown in Appendix A, at strategic 
locations which guarantee the flushing of all modified cache 
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blocks prior to the reassignment of the virtual address 
range. 

The set of three flush commands defined above, together 
with their respective "match" criteria, constitute an 
efficient virtual address reassignment mechanism when placed 
in the Unix kernel as shown in Appendix A* The mechanism is 
efficient in that it optimises flush performance for the 
virtual address write back cache for the three cases of 
virtual address reassignment required by the operating 
system: 

1) whenever an existing active context is being 
replaced by a new context; 

2) whenever HKU limitations require the reassignment of 
a currently mapped segment to a new segment; and 

3) whenever a physical page in memory is to be 
reassigned to a new virtual address. 

The three flush commands are defined, together with the 
flush match criteria, to specifically cover each of these 
cases. Flush commands are issued by the kernel by starting 
at a base block address, and then incrementing block 
addresses so as to check every block within a fixed address 
range. 'The flush commands as defined are efficient in 
address reassignment for two primary reasons: 
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1) The flush match criteria restrict the number of 
blocks flushed to be only those blocks which require 
flushing within the flush address range. Other extraneous 
addresses, outside the flush range, are checked but are not 
flushed. 

2) For each of the three cases requiring address 
flushing, the defined flush commands allow the cache to be 
checked with a single pass through the appropriate cache 
block address range. For example, to flush a segment, every 
page within the segment must be flushed. If a segment flush 
were not implemented, then multiple passes of page flusR 
commands with varying page addresses might be required to 
complete the segment flush. 

The preferred embodiment of the virtual address cache 
for the address path is shown in Figure 3 and for the data 
path is shown in Figure 5. Flush control logic in the 
preferred embodiment is implemented as showri in Figures 11, 
. 12, the state machine of Figure 13 and timing diagram of 
Figure 14. A best case timing diagram for writes is shown 
in Figure 8 and for reads is shown in Figure 9. 

In addition to -components previously discussed with 
reference to Figure 1, Figure 3 includes virtual address 
register (VAR) 5^ which Btores the current virtual address. 
The elements of the invention appear in Figure 3 are cache 
flush logic 33, the Protection bits (p) in the cache tag 
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array 23, and the flush natch logic 24 which is part of cache hit 
detect log 25. 

Also shown in Figure 5 is data register 61 which stores 
data to be vritten to or which has been read from memory 31 
or cache data array 19. 

In Figures 2, 3, 5, 11 and 12, to avoid unnecessarily 
cluttering the Figures, not all control lines are shown. 
However, the control lines necessary for proper operation of 
the invention can be ascertained from the flow chart of the 
state machines shown in Figures 4, 6, 7 and 13, and timing 
diagrams shown in Figures 8-10 and 14. 

In the flow charts, the following abbreviations are 
utilized; 

MUX - multiplexor 45 
Sel - select 
VX - virtual address 
RA real address 
OE - output enable 
Ack - acknowledge 
Cache Hit? - Did cache "hit" logic 25 

detect a cache hit? (Fig 2a) 
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Cache Protect Violation ? - Did control logic 40 detect a 

detect a cache protect violation? 
(Fig 2b) 

Memory Busy? - Has Memory Busy been asserted? 
MKU Protect Viol? - Did control logic 40 detect a 

MKU protect violation? 

(Fig 2c) 

RAR - real address register 51 
CLK - clock 
Adr - address 
Mem Adr Strobe - memory 31 address strobe 

VAR - virtual address register 5k 
Mem Adr Ack? - Has a memory address acknowledge 
been asserted by memory 31? 
Mem Data Strobe 0? - Has memory data strobe 0 been 

asserted? 

Mem Data Ack 0? - Has memory data acknowledge 0 been 

asserted? 



Kern Data Strobe 1? - Has memory data strobe 1 been 

asserted? 

Kern Data Ac* 1? - Has memory data acknowledge 1 been 

asserted? 

'elk Write Back Buffer - clock write back buffer 39 

CPU Read Cycle? - Is CPU 11 in a read cycle 

Clk Data Reg - clock data register 61 

Valid and Modified Write - Has control logic 40 detected . 

Back Data? Valid bit (V) and Modified bit (M) 

Start write Back Cycle? - Has control logic 40 asserted 

Start Write Back Cycle 

Similar abbreviations are used in the timing diagrams 
of Figures 8-10 and 14. 

The address state machine shown in Figures 4a and 4b 
defines certain of the controls related to the address 
handling portion of cache 19. The cache tags 23 are written 
as Valid during state (w) , following a successful transfer 
of all block data from memory 31. The invention is 
integrated through- the inclusion of the Cache Protection 
Violation test following state (c). If a Protection 
Violation is found on a cache Hit, then the CPU bus cycle is 



terminated immediately with a Bus Error response to the CPU. 
The MMO Protection Violation on the translated address is 
performed later, following state (g) . 

The data state machine shown in Figures 6a - 6d define 
certain controls related to the data transfer portion of the 
cache. Again, the invention is supported by including a 
test for the Cache Protection Violation following state (c) . 
The MMU Protection Violation test on the translated address 
is similarly performed in state (g) . 



The write back state machine shown in Figure 7 defines 
the control of the Write Back bus cycle to memory. This 
cycle may be performed in parallel with CPU cache accesses, 
since both the Write Back controls and data path are 
independent of the cache access controls and data path. As 
described below, the "Memory Busy" signal causes the address 
and data state machines to wait until a previous Write Back 
cycle has completed. 

The write cache miss timing diagram shown in Figure B 
defines the overall timing of a CPU write bus cycle to 
memory which misses the cache. The cache Hit and 
Protection Check occur in cycle (c) in this diagram. 

A part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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Into write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVMX) write cycle, then this cache block 
will be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus timing and the 
Write Back state machine, Figures 10 and 7 respectively. 

The CPU write data is merged with block data 
returned from memory on the first data transfer of a 
Block Read memory bus cycle. During cycles (q) through 
(u) , the CPU Write Output Enable controlling buffers 37 
will be active for only those bytes to be written by 
the CPU, while the Data Register Output Enable 
controlling data register 61 will be active for all 
other bytes. During the second data transfer, cycle 
(w) , the Data Register Output Enables for aU bytes 
will be active. 

The read cache miss timing diagram shown in Figure 9 
defines the overall timing of a CPU read bus cycle to a 
cacheable page in memory which misses the cache. The cache 
Hit and Protection Check occur in cycle (c) in this 
diagram. 

X part of the miss handling sequence includes the 
loading of the current cache block which is being replaced 
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l»to write back buffer 39 in cycles (i) and (m) . The 
translated address for the current cache block is also 
loaded into real address register 51 in cycle (o) . If the 
current cache block is both Valid and Modified from a 
previous CPU (or DVKA) write cycle, then this cache block 
will be writtten back to memory 31 through a Write Back bus 
cycle, described in both the Memory Data Bus Timing and the 
Write Back State Machine, Figures 10a and b arid 7 respectively. 

Data is read to the CPU by simultaneously bypassing the 
data to the CPU through buffers 37 enabled by control signal 
CPU Read Output Enable, active in states (q) through (u), 
and updating the cache, in state (s) . The memory is designed 
to always return the "missing data" on the first 64 bit 
transfer, of a Block Read memory bus cycle and the alternate 
64 bits on the subsequent transfer. After the CPU read bus 
cycle data is returned, the CPU may run internal cycles 
while the cache is being updated with the second data 
transfer from memory. 

The Memory Data Bus timing shown in Figure 10a and 10b. 
■hows the timing of Block Read and Write Back bus cycles. 
Since the cache block size is 128 bits, each cache block 
update requires two data transfers. As indicated above the 
64 bite, containing the data addressed by CPU 11 are always 
returned on the first transfer for Block Read bus cycles. 
The "Memory Busy" control signal active during the Write 
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Back cycle is used to Inhibit the start of the next cache 
miss cycle until the previous Write Back cycle can complete. 

Cache flush logic 33 shown in Figure 11 outlines the 
control and data path of the flush controller. This 
controller implements the cache flush operations of the 
present invention for a system with multiple active user 
contexts and a shared operating system. Cache flush logic 
comprises AND gate 48 , flip-flops 49, flush address register 
52, incrementer 50, AND gates 55 and OR gate 58. 

Three flush match signals are used by cache flush logic 
33 to determine whether the addressed cache block is to be 
flushed. Corresponding to the three flush match signals are 
three flush commands issued by the CPU. A Flush Match is 
said to occur if: 

(Context Flush Command.) AND (Context Flush Hatch Signal) 
OR (Segment Flush Command ) AND (Segment Flush Match Signal) 
OR (Page Flush Command) AND (Page Flush Match Signal) . 
An implementation of such flush match logic is shown in 

-Figure 12 comprising comparators 60, AND gate 62, Inverter 

64, OR gate 66 and AND gates 68. 

Flush control logic 33 involves two distinct phases, 
which are shown as separate sequences in the flush state 
machine". Figure 13. The first phase involves decoding a 
Flush command from the CPU and obtaining bus mastership for 
the Flush Control State Machine. The Flush command is 
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issued by the CPU In Control Space (identified by Function 
Code bite FC (2:0) -0x3). Within Control Space, the four high 
order address bits A(31:2B)-0xA indicate the Flush command. 
The address field A(27:0) for the command correspond to the 
28 bit virtual address field for data accesses. The Flush 
command data bits B(l:0) encode the type of flush. After 
the Flush command is decoded, the address field A(27:9) i» 
latched together with the type of flush. A Bus Request 
signal is asserted to the CPU to . obtain bus mastership. 

The second phase involves performing DVMA cycles to 
test and flush, if necessary, 32 cache blocks using cache 
flush logic 33 as a DVMA device. This DVMA device addresses 
cache blocks with the virtual address A(27:9) captured from 
the flush command, plus address bits A(8:4) from an internal 
5 bit flush address counter 50. Bach cache block may be 
checked in three cycles, with the three Flush Hatch signals 
gated by the Flush command latches 55 to determine a -Flush 
Match" condition. A -Flush Match" results in the cache 
block being invalidated and a Modified block being written 
to memory through the Write Back state machine. Following 
the conclusion of the 32 block check, bus mastership may be 
returned to the CPU. 

Kote that as a DVMA device, the cache flush logic 33 
competed with other DVMA devices for bus ownership. Of the 
possible three DVMA devices, Ethernet (not shown) has the 
highest priority; the cache flush logic 33 second priority; 
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and VHEbus devices third.' The flush control state machine 
does not include a complete arbitration description for all 
DVKA devices, but rather only logic related to the Plush. 

The cache flush state aachine shown in Figure 13 
comprises four interacting aachines vhich control the flush 
operation. These four aachines control the decode of the 
CPU Flush command and its application to 32 cache blocks. 
The four machines are described below: 

1) The Command Decode machine decodes the Flush command 
executed by the CFO. Upon decoding a Flush command, 
the flush virtual address A(27:9) and the type of Flush 
command are latched. The machine asserts a Bus Request 
to the CPU to obtain bus mastership for the flush state 
machine. It also asserts a Flush Request signal to 
activate the DVKA machine, below. 

2) The DVKA machine obtains bus mastership from the 
CPU, as indicated by the CPU's asserting Bub Grant, and 
holds mastership by asserting Bus Grant Acknowledge. 

It arbitrates the Flush with the higher priority 
Ethernet requests. 

3) The Flush Compare machine initializes its address 
counter A{8:4) to 0 with the Flush Request, signal. It 
continues to check cache blocks as long as Flush Go is 
asserted by the DVKA machine. When Flush Go is 
deasserted, a Flush Done signal is set at the 
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conclusion of the current block flush, vhich signals 
the DVKA machine to grant mastership to the Ethernet 
handler. If a Flush Match is detected, the Flush Block 
Request signal Is asserted to activate the Flush Match 
machine. At the conclusion of the Flush Match machine, 
this machine returns a Write Back Request signal to 
' complete the machine's handling of the current cache 
block. 

4) The Flush Match machine loads the cache data into 
write back buffer 39, clocks the translated cache 
address in real address register. 51, and invalidates 
the cache tags 33. Note that no protection check is 
performed. At the conclusion, the Write Back Request 
signal is asserted. If the cache block is marked as 
Modified, the Start Write Back Cycle signal is also 
asserted to activate the write back state machine shown 
in Figure 7. 

Figure 14 shows cache flush timing and describes the 
timing of a block flush in the event of a "Flush Match". 
This condition is tested in state (c) . The block is 
invalidated in state (k) . If the block satisfies the "Flush 
Match" and is Modified, then it must be written back to 
memory. A "Start Write Back Cycle" signal is asserted in 
state (s) to begin the Write Back state machine. 
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The kernel changes needed to support the virtual 
address write back cache of the present invention for 
Unix operating system are shown in Appendix A. 



b^l Design ©ocumwt tox Virtual Address Cadh. 

*» l^gJBJW—^ot,-.. ef th . virtual 
cache i/ahort>, «e keep the following invariant condition true at .11 
times. 

If ma entry is In the cube, its sapping from virtual 
address to physical address anst ba correct. 

this is a suf ficiant condition ter the corractnass of the eyste* 

^"•"h.'-Spin^rcPrr.et, reading a byte/word from the 

cache is *he same as reading it from tba physical memory through MOT 

S^^J&& t 7& a £ k . V S5i «&£ SShTeorraspondlng 

It is claax that tha above invariant condition can ba kept 
if w. flush tha ISactad cacba lines before a virtual to physical 
mapping btemi ineerneti 

II. S^.^Hgiaa g|S|fg£f 4 time-eoneuming, w. avoid cache 

l> SushinTif we een?* & a MH-3/200 mechina, a page flush take. 
£ lass* than 50 microseconds and a segment or. 
takes no less than 400 microseconds, excluding the overhead 

2) & a *!a7^S?S!Si addresses, If both virtual 

' can be accessed simultaneously, they have to be arranged to 
mateh in their low order It bits, i.e. awdulo 12SK, ae 
described in the Sun-3 Architecture Manual . Otherwise, i.e. 
if they are aeeessed one at a time, we consider the 
currently used napping correct and other mapping! 
tSSSSSSL ai thi. P ?iml. That is, the virt ual •* 
ether not-currently-used mappings are not in the caene. 

3) Ke ignore the problems of reading /dev/mem £*ause . 

a) access of /dev/mem is not guaranteed to be consistent 
even -on systems without the virtual address cache, 2) such 
edderf inconsistence is minimal, (beeause most of such usages 
Ire for the "areas of non-running processes and these u pages 
E. elreadj flushed during context switches), 
Sstam behaves as the system yit^ t e « h ^« e ^5^\i'fS. B . d 
turn off the cache of the entire aystem while /dey/mem is opened 
Sis San! any user process can slow down the entire system 
considerably by open /dev/mem. 



m ' ^»h^f!n§w#reutin.. are added to the kernel, 



_i« — vi , »T ,c - ck f fl ** hH tha cache by eontext-aateh. It fluahea 

SLf!??-^?* W«vl.or bits la th* Mcbi tSTrioff AMD whoa* 

X^e. it flash** an entire user contact. .vacjetxf luah () is defined la 

— . -« .. 2, v *e_aegflueh(eeg»eBt .number) fluahea the each* bv uaniBtwiteii 
St fluahea all eadha Unas wheae aegaent addraaa partT €A««-2??l2 * 
ef the cache tag match •aa B i B eat_w»Jar^«lthar"rSS 1 k£nel iddreaa 
apace or from th. currant uaar'e addrass apaea. i?*? it™lu.t.r.£her 

Ire? : lSli t a-" t-1 tht W ^ of^rtuafaddSsS ISh.r 

f* « *i * dd f*" »P»e» or £x«n tha currant user'* addrass anae. 
I.*. It flu.he. althar a karaal page or a near paae ef th* eu**!??^.,. 
context. vac_pagaflu.hO ±« Defined la «ap.I? *** C ° re * at °" r 

, »«e_fiu*h(virtualjeddr*aa, number of byte.) fluahea thm each* 

Olnaa whoa* paga addrass part. (A<13-27> la SCH-3) It tha Mcha tlo^! «« 
SV^!' S I"»ift»*l •dor...-, -virtual .SS...-°; SSaSr of -^1 
It flush., the.. Haas althar from a karaal addrass sp.cTor ?roaf thl 1 
currant near'* addraas apaea. vac flush () Is need either to f luah lZae 
*haa a paga, such as from re«ume(>7 or to f lush a aumber of cSSoWl 
P.ga., auch a. from p»g.out(). vac_flu.h() li da£iSSd L ■*?!.? ^ 

tha antir. 2cF??o\^^^^ SyaVeL^ 

_ fc . M .,fi.I' e r?fl? bl *-^*2*, (vlrt ?* 1 -* d,Ir * B I> turn » off tha caching of 
a karaal paga ataxtlng at "virtual addrass"! It is uaed bv the m.^iZ. 
driver s»ap() routina to aaforca tno consist? of aharino a kaSll^paaa 
•ita asar pagaa. vae.disablejcpage {) la defined la v»_s^dap.c. 

' . 7 > vac_anabla_kpaga (virtual addrass) tarns on tha cachino ef a 

karaal paga ataxtlng at "virtual_addreaa- . If a d.vic. driv.r aSaS 
routine knows that no mora ussr pages are aharino a kernel mo* iX 
call, vae .nabieJcpagaO to allow the eaehing of'tSu kernel £«t 
vac_enabl._kpag.() la defined la vm_xnaehdep.e p ** # * 

IV. Where and how do we flush the cacha? 

1} ? B ^L^f-f X "?f^?^ rctxfr * e0 in vnjMchd.p.c. 
2 JTv **• ( 2v lB eml f * d whwi • context la freed from HMD 
E^! 06 ? n f&?2 of th * %,he>1# context la not valid. 

11 c*liad from etxallocO whan tha oldest 
context is boaped out ef KMU, from swapeutO whan a 

5T22t«»*l! W 2 ?*' from ,xlt< » « h « n • P»oaaa 
la terminated, and from ptexpaad() when this context 

•t- 5 s 9i y? n °« fos * **• Pt*'a are axpandad. ) 
* TV*^ 1 »f e - o f««4«»0 from vrelv&O la v«proe.c. 
iv*!!^"-^? 1 "*'!?! *«»ourcas associated with this 

process. Shla will causa all virtual and physical pages of 
the procaas be relaaaad and thua invalidate- all virtual to 
a. E^* 1 ?* 1 «*PPin9» the currant context. > «c 
1 ef^^^e-CtxfluahO from expand () la vn _pree.e. 

aoml virtSS^S. V SOee " '^^^ « d *t give, back 
4> '»e_ctxflu*h« from ovadvisaO la kam anan.e. 

llf^n! f.C? XW,B i e ? *° i« VA_rLDSH,~w. Invalidate 

S £11 i?.!?'^*" °* tb ; "» r »« n t Proeees. A context flush 
.. *» «*«icient than a number of page flush.. . 1 

f PaeareleaeeO ia called whan a pnee is taken awav. 
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FmegreleaseO can be called by cither pmegalloeO or 
pmegallocres () • ) 

6) He call vac segflusM) f rem pmagload () in vmjsaehd^p.e. 

( A aegment"in the bole is to be freed and eet to 6EGXNV 
in the segment nap. ) 

7) Ke call vac page flu oh {) from pageoutO in vm page.c. 

( This is when a page is marked invalid by the pageont 
demon. ) 

8} Ke call vac pagef lush () from ovadviseO in kern_anan.c. 
( Shis is WKen ovadviseO narks a page invalid. ) 

9) We call vac pagef lush () from napoutO of vmjnachdep.c. 
{ Mapout () Is called to release a napping from kernel 
virtual address to physical address. 

Mapout () is called front 

a) physstrat 0 when napping f con kernel virtual address to 

user buffer address is released. - 
1}) wmemfreeO 

c) cleanup () 

d) ptexpandO to release old page tables. > 

10) We call vac_pagef lush (> f rom pagenove () of vm_naehdep.e. 

{ In pagemoveO %re call vac^agef lush (to) because the napping 
of "to" to its physical page is .not valid after setpgmapO call. 
We call vac_pagef lush (from) because the napping of "from" 
to the physical page is not valid after the aecond 
setpgmapO call. ) 

11) Ke call vae_pagef lush () from mbr else () of sundev/mb.e. 

{ This is when setpgmap(addr, 0) is called to invalidate 
the mapping from DVHX virtual addresses to physical 
addresses. ) 

12) Ke call vac_flush() from resume () in vax.s. 

{ At the end~of context switch timer the napping of the 
outgoing process's u becomes invalid. Ke should flush 
the outgoing process's u before its u napping becomes invalid. 
Since context switch happens very frequent f we only flushes 
the user struct and the kernel stack , instead of flushing 
the entire u page. (Resume () is also called from procdupO 
to force an update of u.) ) 

13) Ke call v»c_flush() from smmapO, nunmapO, and nunmapfdO 
in kern smanTc. 

{ Virtual to physical mappings of some pages are changed. } 

14) Ke call vac_f lu shall () from dumpsysO of m^chdep.c to 
flush out the content of the entire vac to physical memory 
in order to dump out the physical memory. 

15) There are a number of places where virtual-to-physical 
mappings are invalidated implicitly , e.g. the pme/pte mapping 
is still valid but this mapping is never used again. Ke 
must flush the associated portion of cache, otherwise, when 

a new napping is set up from this virtual address, the 
cache may contain some lines of the previous mapping. 

a) Ke call vac_pageflush() from mbsetupO of sundev/mb.c. 
{ Zn mbsetupO, the mapping from pte's to physical 
pages is temporarily (until mbrelase) replaced by the 
napping from DVMA virtual addresses. ) 

b) Ke call vacjpagef lush () from dumpsysO of nachdep.c. 

* 1 The last page in the DVMA region is used to nap to one 
physical page at a time to dump out the physical memory. 
Such a napping is invalid each time after ("dumper) () 
is called. ) 

c) Ke call vac_pageflush() from physstrat 0 of nachdep.c. 
{ Zn physstrat O, "user" pages are doubly mapped to 
the kernel space. Ke flush these user pages when we eat 

up the associated kernel pages. Xater, these mappings from 
kernel virtual pages to physical pages are invalidated by 
mapout 0, there these kernel virtual addresses are 
flushed. ) 

d) Ke call vac paaeflushO from eopvsecrO of nachdep.c. 



{ Xn copysegO* the mapping from virtual address CADDR1 
to physical Address •pg»o" becomes Invalid after copyinO. 

e) ire call vacj>agef lush [) fromanzv() of sun3/nea.c. 

j Xn ntnrwO, the napping from •vmnap" to a physical address 
is set up to copy physical data to the user apace. Shis 
napping becomes invalid after uiomoveO • ) 

f) Me call vac_pagef lush {) from pageinO in vm page.c. 

{ The napping from CADDR1 to physical page pf+1 beeones 
Invalid after breroO* > 

g) Vie call vacjflushO from procdupO of vnproc.c 

to flush the kernel stack and u * parts of forkutl. 

( In procdupO, forkutl naps to~the physical u page 

of the child process through vgetu()« 

Since the napping from forkutl to the physical u page 

of the child becomes Invalid when the parent returns fron 

procdupO* forkutl is flushed before procdupO returns. 

h) He call vacjflushO from newprocO of kern fork.c 
to flush the u_* part of vfutl. ~ 

{ Xn newprocOT in the case of vfork, vfutl naps to 
the physical page of the child through uaccess(). 
This napping is not used anymore after vpassvmO 
Is called. ) 

i) He call vac_flushO from svapoutO of vm swap.e 
to flush the u_* part of utl. *" 

{ Xn swapoutO* napping from utl, which is either 
xswaputl or xswap2utl, to the physical u page of proc p 
. is Invalid after proc p is swapped out. ) 
j) He call vacjflushO from swapin() of vm swap.e 
to flush the u_* part of utl. ~ 
{ Xn swapin() f "napping from swaputl to the physical 
u page of proc p becomes invalid before we return from 
awapinO. J 

k) He call vac_pagef lush () from swapO of vm swp.e. 

{ The napping from i-th virtual page of process 2 to 
the physical page is not valid anymore. } 

1) He call vacjflushO from pageoutO of vmpage.c 
• to flush the uj* part of puahutl. 

( Xn pageout()7 the napping from puahutl to the physical 
u page of rp becomes invalid after the vtod() call. ) 

n) He call vac flush 0 from pageoutO of vmj^age.c to 
flush the cluster of pages to be paged out. 
{ SwapO naps the physical pages of these pages to virtual 
addresses of proc [2] before it calls physstratO. Thus, 
the mappings from the outgoing virtual pages to physical 
pages are to be replaced by those of proc [2] virtual pages 
to these physical pages. Therefore, we flush these pages 
In pageoutO before swapO is called. } 

n) He call vac page flush () from kmcopy () of vnjpt.e. 
{ kmcopyO Is called from ptexpandO to "copy" pte'a 
from old pte'a to new pte's. Xt •copies" by napinO 
new pte's to the physical pages of old pte'a. He flush 
old pte's before new pte's are mapped-in. } 

o) HSs call vac_pagef lush () from distpteO of vmjt.e. 
{ distpte 0 is called when the pte entries of a shared 
text pte is changed. For example, pageoutO changes its 
valid bit to invalid. Since other processes sharing this 
text page nay have this text page in the cache, we flush 
out this page for all sharing processes. ) 

p) He call vac flush () from vrelptO of vmjpt.c to flush 
the pte's of the outgoing process. 

I Xn vxelptO, the pages that contains pte's are released 
but napoutO is not called. } 
q) He call vac_pagef lush 0 from wlok unlock of 
aunwindowdev/winlock.c. ~ 



{ In wlok unlock () r mapping from wlock->lokjaaer 
to the physical u page of the current process becomes 
invalid if wlock-> lok user is nonzero. > 
r) We call vacjpegef lush (7 from wlokjdone () of 
sunwindewdev/winlock. c. 

{ In wlok done(), the mapping from wlock->l©kjaeer 
to the physical u page becomes invalid. ) 
16) When protection bits are changed and the affected portion 
of the cache should be flushed. Such places ares 

a) in chgprotO of vm machdep.c, we change the protection 
of text pages. We~call vac page flush () there to avoid 
having any entry in the cache with different protection 
with the HMD. 

b) in settprocO of vm machdep.c we change the protection 
bits of text pages ~ We call vacJClushO to flush 

the text part of the process. (settprotO ±» called 
from vm text.e.) 

c) in vac disable kpageO of vmjnaehdep.c we call 
vae_pageflush(T to flush all cache lines of this page 
before making the page non-cached. 

V. Why don't we flush the cache here? 

— Trhe~foIlowing IFa list oTplaees where the mapping from 
virtual addresses to physical addresses are changed but the cache 
is not flushed. We describe the reasons why cache flushings 
are not necessary. ^ . , , 

1) In ctxpassO of vm machdep.c, the virtual to physical 
mapping of proc p is changed to that of proe q. But, q 
gets whatever in the cache previous belong to p, so no 
need to flush cache for p. 

{ ctxpassO is called by vpassptO to pass the context of p 
to q. vpassptO is called by vpassvmO which is called before 
and after vforkO . vpassvmO passes the vm resources and 
the MMU context of p to q. When vpassvmO returns , the 
virtual to physical mapping for the context is not changed. 
Since the context is also passed, the affected mappings in 
the cache are still correct, except that now they belong to 
proc q instead of proc p. Therefore, there is no need to 
flush the cache either in ctxpassO or in vpassvmO . > 

2) In vpassptO, the virtual-to-phyaical mappings of processes 
"up* and "uq" are not changed when vpassptO returns. 

(Or more precisely, the mappinga are changed back to 
the same as the mappings when vpasspt 0 is entered) • 

3) Zn swapO of vm swp.e, if •flag" indicates a dirty page 
push, the mapping of addr to physical address is replaced 
by that of the i-th page of proc 12]. Since dirty pages 
have been flushed in pageoutO/ there is no need to flush 
■addr* again in swapO. 

4) Zn pmegloadO of vm machdep.c, when *pmxp (ctx nmegleeg] > 
is sero and Ineed, we invalidate pmeg[seg]. Since we did 
either a context flush (in etxfreeO) or a segment flush 
(in poegreleaseO) when we set ctx pmegtseg] to zero, 
there is no need to do a segment flush here. 

{ There are only two places where we set (struct context •)•> 
. ctxjmegtseg] to sero. One is in pmegreleaseO where we 
vac segflush(seg) and setsegmap(seg, SEGZNV) . 
The^other place is in etxfreeO where we call vac_etxf lush () 
but don't setsegmap(seg, 5EGINV) . 

Hence (struct context *)->ctx_pmeg[eegl is sero but HMD 
eegmap is not 5EGZHV in this case. The reason that 
when *pmxp — 0 and fneed in pmegloadO needs a 
setsegmap(seg, SEGZNV) ie to make MKO aegmap to be SEGINV. 
Since we have done a vec_ctxf lush 0 in etxfreeO, this 
segment should not have any left-over in the cache. } 

5) Zn ctxallocO of vm machdep.c, eetsegmapO i» called 
to invalidate all mappinas from the seament map. Since 



etxfreeO i» called earlier to flush the entire 

context, no lines associated with those segments 

are in the cache. Therefore, segment flushes axe not 

6) In ptesyneO of *m machdep . e, ' pteeync { ) calls poegunloadO 
which ©r'a the HOdTbita to pte's end reset the mod bits of 

the pmeg. When we check if another page in this pmeg is dirty, 
we check its pte' which remembers the nod bit was en. 
We don't need to flush the segment because pmegunload turns 
off the mod bits in this pmeg. 

7) unloadpgmap () of map. a saves the referenced and modified 
bits from MOT pme to soft pte and dears these bits in the 
pme. Since when we do pageout ©r swapout, it is the soft 
pte that we cheek to decide if a page is dirty, there is no 
need to flush the cache when the referenced and a»dified 
bits of a pme is changed. ,„„,- 

6) In pmegunload () of vmjnaehdep.c, we call setsegmap (CSEG, 
pmp-praeg), unloadpgmap ( v, pte, num), and setsegmap (CSEG, 
SEGIKV) . In unloadpgmap () , segment map of CSEG is used to 
access the pine's in this segment. Virtual address of 
segment CSEG is not accessed, thus segment CSEG doesn't 
have anything in the cache. Therefore, there is no need 
to call vacjaegf lush (CSEG) before we invalidate this 

9) Xn'mapoutO of vmjnaehdep.c, when we invalidate a segment 

by calling setsegmap ((uint)ptds(btop(vaddr)), (u.eharJSEGIHV), 
we have done pageflushes on all previously used pages in this 
segment. Therefore, there is no need to do a segment flush. 
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CLAIMS 

.1. In a workstation utilizing a virtual address write back 
cache including a central processor having an address bus and a 
data bus, a cache data array, having a plurality of cache blocks, 
a cache tag array having an array element for each of said cache 
blocks, each of said array elements having a Valid bit, a Modified 
bit and a Supervisor Protect bit, a write back buffer, a memory 
management unit, a main memory, a cache hit detector, a context 
identification register, flush control logic and workstation 
control logic, the improvement wherein said cache hit detector is 
modified to detect cache hits in a Bhared operating system across 
multiple active user contexts, and wherein said workstation further 
comprises: 

a) means for reassigning virtual addresses across multiple 
user contexts; 

b) means for completing a cache block flush operation before 

control is returned to the central processor upon the issuance of a 

flush command, and in each said flush operation, flushing all cache 

■ 

blocks having their associated cache tag array element Valid bit 
set, prior to reassignment of the virtual addresses. 

2. The improvement defined by Claim 1 wherein said modified 
cache hit detector comprises: 

a) means for detecting cache blocks having their corresponding 
cache tag array element Valid bit set; 



b) first means for determining whether for the cache block 
being addressed by the central processor, said cache block address 
having a plurality of access virtual address bits, said access 
virtual address bits match virtual address field bits in a 
corresponding cache tag array element* 

c) second means for determining whether i) for the cache block 
being addressed by the central processor, said said cache block 
address having a plurality of access context bits, said access 
context bits match context bits in the corresponding cache tag 
array element; and ii) the Supervisor Protect bit is set in the 
corresponding cache tag array element. 

3. The improvement defined by Claim 1 wherein said 
reassigning means comprises: 

a set of flush commands disposed within the shared operating 
system, said flush commands being a context match flush command, a 
page match flush command, and a segment match flush command. 

4. The improvement defined by Claim 1 wherein said flush 
operation completing means comprises: 

a) means for decoding said flush command, said flush command 
being one of a context match flush command, page match flush 
command and segment match flush command; 

b) flush address register means for storing an address 
included in said decoded flush command; 



c) incrementing means for incrementing predetermined address 
bits for combining with the address bits in said flush address 
register means; 

d) flush match means coupled to said decoding means for 
generating a flush match logic signal, 

whereby the issuance of a flush command causes all cache 
blocks having their associated Valid bit set to be flushed prior to 
reassignment of the virtual addresses. 

5* The improvement defined by Claim 2 wherein said detecting 
means comprises a first AND gate having a first input coupled to 
the Valid bit of the array element in the cache tag array 
corresponding to the cache block being addressed by the central 
processor. 

& The improvement defined by Claim 5 wherein said first 
determining means comprises a first comparator coupled to said 
address bus and said cache tag array, the output of said first 
comparator coupled to a second input of said first AND gate. 

7. The improvement defined by Claim 6 wherein said second 
determining means comprises a second comparator coupled to said 
context identification register and said cache tag array, the 
output of said second comparator coupled to a first input of an XOR 
gate, a second input of said XOR gate coupled to the Supervisor 
Protect bit in the cache tag array element corresponding to the 
cache block addressed by the central processor. 



B. Ihe improvement defined by Claim 7 wherein said modified 
cache hit detector further comprises: 

a) a second AMD gate having one input coupled to the output of 
.aid XOR gate, a second input coupled to the output of said first 
AND gate and a third input coupled to the output of a third 
comparator whose inputs are coupled to said address bus and the 
array element of said cache tag array addressed by said central 
processor} 

b) a fourth comparator whose inputs are coupled to said 
address bus and the array element of said cache tag array addressed 
by said central processor, the output of said fourth comparator 
being a third input of said first AMD gate. 

9 . The improvement defined by Claim k wherein said 
decoding means comprises an AND gate coupled to said central 
processor and first, second and third flip-flops having their clock 
inputs coupled to the output of said AMD gate and their D-inputs 
coupled to said data bus. 

iq. The iaprovement defined by Claim ? wherein said 
flush address register means comprises a register which loads 
predetermined bits from the address bus when the output of said AND 
gate is set. 

11. The improvement defined by Claim 9 wherein said 
flush match means comprises first, second and third AND gates, each 
having one input coupled to the Q outputs of said first, second and 



third flip-flops respectively and a second input coupled to naane 
for generating a segment aatch signal, a page natch signal and a 
contajct Jnatch signal, an OR gate having first, second and third 
inputs coupled respectively to the outputs of said first, second 
and third AMD gates, vhereby the output of said OR gate is set when 
ens of said segment, page and context Batch signals are set and a 
corresponding segment, page and segment command has been decoded. 
12. A workstation ei&etentially as herein described with reference to 
end as illustrated in the accompanying drawings. 
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